Subject: Bernie Brady's 3/8 append on flow control

From: [email-masked]
Date: Wed, 9 Mar 94 23:55:04 EST

>Peter,
>
>Overall the proposal looks great, but I have a question on the following
>statement.
>
>>Pacing is done on a circuit basis only, in both directions independently.
>>The pacing receiver controls via a sliding cumulative window how many
>>frames a sender may put on the transport connection, for a given circuit.
>>Pacing is applied only to SSP message types INFOFRAME and DGRMFRAME.  The
>>point at which a DLSw node should RNR a data link or begin to discard
>>UI-frames is an implementation issue for the router and is not specified
>>by this pacing architecture.
>>
>
>I think that this section should be re-worded as follows:
>
>        Pacing is done on a circuit basis only, in both directions
>        independently. The pacing receiver controls via a sliding
>        cumulative window how many frames a sender may put on the
>        transport connection, for a given circuit. Pacing is applied
>        only to SSP message type INFOFRAME.  The point at which a DLSw
>        node should RNR a data link or begin to discard UI-frames is an
>        implementation issue for the router and is not specified by this
>        pacing architecture.
>
>I remove the DGRMFRAME, if not then  the last sentence conflicts.
>
>Bernie

Bernie,
I don't see the conflict in the sentence you mention.  I meant for
the phrase "RNR a data link" to refer to what one might do to control
the I-frames (potential INFOFRAMEs) and "discard UI-frames" to refer
to how you would get rid of potential DGRMFRAMEs.  Maybe this needs
to be worded better?

In any case, I thought we reached consensus at the September AIW to pace
both I-frames and UI-frames.  I don't think Shannon restated this
point in Anaheim, but I'm pretty sure it's documented in a number of
old postings.  Do you feel we should not count UI-frames?  This is
only an issue for NetBIOS connections, but there it can be a real
issue.

Peter